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AN OBJECT ORIENTED BASED, BUSINESS CLASS METHODOLOGY 
FOR GENERATING QUASI -STATIC WEB PAGES 

5 BACKGROUND OF THE INVENTION 

(1) Field of the Invention 

This invention relates to a method for enhancing the 
retrieval of dynamic, web-based data, and more particularly to 
a methodology for generating quasi-static web page versions of 
10 dynamic web pages at predefined intervals. 

(2) Description of the Related Art 

With reference to Fig. 15, there is illustrated a typical 
web server architecture for assembling and delivering web 

15 content to a plurality of web browsers as known from the prior 
art. A plurality of web browsers 1511 are illustrated with 
each web browser 1511 in connectivity with network router 1515. 

As used herein, "connectivity" refers to the ability of two 
entities to exchange electronic information. Network router 

20 1515 is in connectivity with web server component 1517. Web 

server component 1517 is comprised in part of web server 1519. 

Each web browser 1511 has access to cached data 1513. Cached 
data 1513 is data which is transient in nature and is stored in 
a format accessible to the device which has cached it. Cached 

25 data 1513 may reside in local memory, may be stored on a hard 
drive, or may exist in any format and on any medium capable of 
storing, retrieving, and sending cached data 1513 as requested 
by another device. Router 1515 is likewise in connectivity 
with cached data 1513. When a user requests information from a 

30 web server, the retrieved data may be stored for defined 

periods of time in several places as the requested data makes 
its way to the requesting web browser 1513. 

These temporary storehouses of cached data 1513 serve to 

1 
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minimize the bottlencks which can form around operational 
databases in connectivity with web server 1519. For example, 
many users of web browsers 1511 may request within a short 
period of time the same web page from a web server 1519. It is 
5 not uncommon for the home page of a web site to be static in 
nature. As used herein, static data is data which does not 
change over relatively long periods of time. The length of 
such periods of time varies depending upon the precise nature 
of the data but is typically on the order of days, weeks, or 

10 longer. As users navigate throughout a web site, the choices 
which a user makes will likely necessitate the creation by the 
web server 1519 of web pages containing dynamic data. As used 
herein, dynamic data is data which changes over relatively 
short periods of time or which cannot be derived prior to a 

15 request for such data. The length of such periods of time 

varies depending upon the precise nature of the data but is 
typically on the order of minutes or hours. For example, after 
entering a web site, a user may request data pertaining to a 
plurality of products of interest. The web page which is 

20 assembled and sent to the web browser 1511 by the web server 
1519 in response to such a request is formed of a particular 
set of product information which could not have been 
ascertained prior to receiving the user's request. 

While requests for web pages containing dynamic data 

25 require interaction with the web server, many requests for web 
pages involve only static data and may therefore be cached for 
more effective delivery. Such caching is commonplace in the 
existing art. For example, a network router 1515 may store in 
its cached data 1513 every web page which it returns to a web 

30 browser 1511 as the result of routing the request to the web 

server 1519, receiving a response therefrom, and forwarding the 
response in the form of a web page back to web browser 1511. 
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The length of time for which the network router's 1515 cached 
data 1513 is to remain resident in memory or otherwise 
accessible is a system parameter which may be set by the 
network administrator or other appropriate personnel or 
5 application. In this manner, subsequent requests of the 

network router 1515 by web browsers 1511 to retrieve a web page 
that has been cached by the network router 1515 may be 
satisfied by retrieving the web page not from the web server 
1519 but from the network router's 1515 cached data 1513. In a 

10 similar manner, once a web page has been requested and received 
by a web browser 1511, the page will typically be stored by the 
web browser 1511 in cached data 1513 connected to the browser. 

Subsequent requests by the web browser 1511 for a web page 
that has been cached may result in the retrieval of the 

15 requested web page from cached data 1513 in connectivity with 
the web browser 1511 rather than being retrieved from the web 
server 1519 . 

In this manner, a typical network architecture can 
minimize the severity of web server 1519 bottlenecks. When a 

20 web browser 1511 requests a web page, the web browser 1511 

checks to see if there is a copy resident in its cached data 
1513. If there is, the cached web page is retrieved. If there 
is not a copy resident in the cached data 1513, the request is 
passed to the network router 1515. Similarly, the network 

25 router 1515 checks to see if it possesses a copy of the 

requested web page in its cached data 1513 . If it does possess 
a copy, it retrieves the copy and passes it back to web browser 
1511. If it does not possess a copy in cached data 1513, it 
passes the request on to web server 1519. 

30 At each point in the network where caching takes place, it 

is possible to designate the period of time during which each 
copy of cached data 1513 is to remain valid. For example, a 
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web browser 1511 may be configured to allow cached data to 
remain valid for a period of minutes, for the duration of the 
current session, or to remain valid in subsequent sessions. 
Network router 1515 may be configured to maintain cached data 
5 1513 as valid for any desired period. In addition, at any 

time, a user may select the refresh option on web browser 1511 
and force an update from web server 1519 rather from any cached 
data 1513 version located anywhere throughout the network. 
With reference to Fig. 16 there is illustrated a more 

10 detailed representation of a typical web server component 1517' 
as known from the prior art. Web server component 1517' 
includes an additional methodology by which web pages may be 
assembled for delivery by a web server 1519. As illustrated, 
web server component 1517' is additionally comprised of 

15 connection 1627, executable 1621, executable repository 1623, 
and operational database 1625. Connection 1627 comprises the 
interface which provides connectivity between web server 1519 
and network router 1515. Executable 1621 is a self contained 
application that, when invoked by web server 1519, assembles a 

20 web page and sends it to the requesting web browser 1511 via 
connection 1627. Executable 1621 has access to executable 
repository 1623 which serves as a memory device in which 
executable 1621 can store the results of its execution. 
Operational database 1625 maintains the run-time data of the 

25 network architecture. This data may be stored in, but is not 
limited to, a relational database. 

Instead of requesting a web page, a web browser 1511 may 
instead request the invocation of executable 1621. Executable 
1621, when invoked, executes to assemble a web page which 

30 matches the request and returns the web page to web browser 

1511 via router 1515. One common language in which executable 
1621 is written is Active Server Pages or ASP. ASP is an 
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interpreted language which contains static text, such as HTML, 
as well as ASP commands. Typical ASP commands are delimited by 
character sequences such as w <%" and u %>" . When invoked, the 
ASP code outputs the static HTML code "as is" to executable 
5 repository 1623 while performing the execution of commands 
written in ASP and appending the results to executable 
repository 1623. In this manner, an HTML page may be coded in 
ASP which contains static elements as well as elements which 
are filled at run time by performing data base accesses from 
10 operational database 1625 and the like. While drawn to an ASP 
implementation, executable 1621 may be written in any language 
which returns to the requestor information formatted in an 
appropriate manner. 

The present state of the art requires that a web page be 
15 either static or dynamic in nature. As a result, a page coded 
in ASP, dynamic in nature, will often require the invocation of 
executable 1621 and the attendant access to operational 
database 1625 in order to fulfill a request for the web page 
generated by executable 1621. Such database access can result 
20 in redundant requests of an operational database the result of 
which may be slower system response times. However, data which 
is dynamic is in fact often static over a well defined period 
of time. For example, product price information may be updated 
in operational database 1625 on the last day of each month. If 
25 a web browser 1511 requests a web page illustrating products 
and their prices, web browser 1511 would typically invoke ASP 
code rather than requesting a static web page. This results 
from the fact that product prices change from time to time. 
Were the prices unchanging, a static HTML page could be created 
30 and stored to be sent to web browsers 1511 in the event of a 
request for such information. Therefore, any web page which 
contains dynamic data must be coded in ASP, or a similar 
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language, and will always invoke a retrieval from the 
operational database 1625. 

However, because the dynamic data which records product 
prices changes quite infrequently, being updated only once a 
month, it would be desirable to devise a method whereby 
infrequently changing dynamic data could be handled like static 
HTML data and stored for immediate retrieval without the 
necessity of an operational database 1625 query. There is 
therefore a need in the art to devise a method whereby 
infrequently changing data contained within a web page can be 
generated as a static page, in a format such as HTML, rather 
than as a web page dynamically created by the execution of ASP 
or other code. Such a methodology would serve to reduce the 
bottlenecks formed when data is requested which requires 
interaction with the operational database 1625. 

In contrast to existing methodologies whereby ASP or other 
code is invoked to dynamically create a web page in response to 
a request, there is needed a methodology whereby the same page, 
or substantially the same page, could be requested as a static 
web page thus avoiding unnecessary queries to an operational 
database. Such a methodology would constitute a substantive 
change in the manner by which existing methodologies seek to 
create and return dynamic data in response to user requests. 

BRIEF SUMMARY OF THE INVENTION 
Accordingly, one aspect of the present invention is drawn 
to a method for providing a requestor with access to dynamic 
data via quasi-static data requests, comprising the steps of 
defining a web page, the web page including at least one 
dynamic element, creating an executable digital code to be run 
on a computer and invoked at defined intervals by a scheduler 
component the executable code effective to create and storing a 
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quasi -static copy of the defined web page, creating the 
scheduler component capable of invoking the executable code at 
predefined intervals, loading the executable code and the 
scheduler component onto a platform in connectivity with a web 
server and with one another, invoking execution of the 
scheduler component, and retrieving and returning the static 
copy of the defined web page in response to requests for the 
defined web page. 

Yet another aspect of the present invention is drawn to 
the aforementioned method wherein the web page is defined and 
stored in a centralized repository. 

Yet another aspect of the present invention is drawn to 
the aforementioned method wherein defining the web page 
comprises the steps of defining the placement and method of 
derivation for all elements comprising the web page, and 
defining the web page as either static or dynamic in nature. 

Yet another aspect of the present invention is drawn to 
the aforementioned method wherein the elements are defined as 
dynamic or static in nature. 

Still another aspect of the present invention is drawn to 
the aforementioned method wherein the creation of the 
executable code and the creation of the scheduler component is 
generated from Business Class definitions comprised of the 
defined web pages. 

The method of claim 5 wherein the static copy of the 
defined web page is stored in a format capable of being viewed 
by a web browser. 

The details of one or more embodiments of the invention 
are set forth in the accompanying drawings and the description 
below. Other features, objects, and advantages of the invention 
will be apparent from the description and drawings, and from 
the claims . 
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BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a screen rendering of an Object Modeler GUI in 

accordance with the invention. 

FIG. 2 is a screen rendering of an electronic form based 

Class Editor GUI for editing the properties of Business 

Classes . 

FIG. 3 is a screen rendering of a text -based methodology 
for displaying attribute data using the Class Editor GUI. 

FIG. 4 is a screen rendering of the Class Editor GUI of 
FIG. 2 illustrating class attributes and their attendant 
business rules. 

FIG. 5 is a screen rendering of the business rule portion 
of the Class Editor GUI of FIG. 2. 

FIG. 6 is a screen rendering of a Business Process Editor 

GUI . 

FIG. 7 is a screen rendering of a GUI utilized to display 
Business Methods. 

FIG. 8 is a flow chart of the code generation process of 
the present invention. 

FIG. 9 is a screen rendering of the web page editor of the 
present invention. 

FIG. 10 is a screen rendering of the web page property 
editor of the present invention showing the form specified 
attributes . 

FIG. 10a is a screen rendering of the web page property 
editor of FIG. 10 illustrating the data binding menu. 

FIG. 11 is a screen rendering of the web page property 
editor of the present invention showing the object space 
specified attributes. 
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FIG. 12 is a screen rendering of the web page editor of 
the present invention illustrating the selection and placement 
of graphical and textual elements. 

FIG. 13 is a screen rendering of the control property 
5 window of the present invention. 

FIG. 14 is a screen rendering of the generate HTML window 
of the present invention. 

FIG. 15 is a schematic diagram of a traditional network 
architecture supporting web-based data acquisition as known in 
10 the prior art . 

FIG. 16 is a schematic diagram of a web server component 
as known from the prior art . 

FIG. 17 is a graphic illustration of a static web page and 
the code that defines the static web page as known from the 
15 prior art. 

FIG. 18 is a graphic illustration of a dynamic web page 
and the code that defines the dynamic web page as known from 
the prior art . 

FIG . 19 is a graphic illustration of a dynamic web page 
20 comprised of static and dynamic elements and the code which 

defines the dynamic web page in accordance with the invention. 

FIG . 2 0 is a schematic diagram of the web server component 
of the present invention. 

25 Like reference numbers and designations in the various 

drawings indicate like elements. 

DETAILED DESCRIPTION 
The present invention provides a methodology for 
30 converting web pages comprised, in whole or in part of dynamic 
data, into static HTML coded pages which may be cached as 
desired throughout a network. As used herein, "web page" 
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refers to code viewable by a web browser. As used herein, 
"network" refers to an integrated assemblage of electronic 
components. The result of this conversion is an enhanced 
methodology whereby requested dynamic data contained in an 
5 operational database may be assembled into an equivalent static 
representation of the requested data which does not require 
interaction with the operational database 1625 of Fig. 16. 

The creation of Web Pages and other means of electronic 
communication and data manipulation for architected systems is 
10 defined through the use of Business Classes as described more 
fully below. 

When executing software on a computer, a Business Object 
is a data object, for which storage space on an electronic 
medium has been allocated, derived from a Business Class 

15 template. By template, it is meant that a Business Class 

defines the generic definition of a Business Object. A data 
object is an entity stored in an electronic format that is 
comprised of information. A Business Object is, therefore, a 
dynamically allocated instance of the static Business Class. A 

20 Business Class is comprised of attributes, methods, external 
messages and web documents. Detailed examples of attributes, 
methods, external messages and web documents are provided 
below. The Business Processes, comprising in part the Business 
Class, are themselves comprised of Business Rules, methods, and 

25 subprocesses . Business Rules and Business Processes are defined 
more specifically below. An advantage of the present invention 
is the ability to model all business activities as interactions 
between Business Classes. 

The structure and organization of the Business Class is 

30 such as to uniquely and completely define the attributes of the 
Business Class. Because the Business Class, when implemented 
in computer code will often take the form of an OOP class 
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definition, the structure of Business Classes as herein defined 
bears superficial resemblance to OOP classes. OOP class 
definitions form the core of various OOP languages including, 
but not limited to, C++. However, in accordance with the 
5 present invention, Business Classes are not limited to 

implementations in OOP languages, rather, Business Classes may 
be implemented in non-OOP languages including, but not limited 
to, JAVASCRIPT . Business Class information and definitions are 
stored in a repository in a neutral format from which code can 

10 be generated in any required computer language. 

A subset of characteristics unique to a specific Business 
Class is the relationship between the specific Business Class 
and a plurality of other Business Classes with which the 
specific Business Class interacts. Other characteristics of 

15 the specific Business Class may include attributes, specific to 
the Business Class, which are not dependent upon a relationship 
with other Business Classes. 

Described herein are several methodologies involving 
graphical user interfaces (GUI) which, taken together, allow a 

20 user to diagram at a high level a plurality of Business 

Classes, the relationships between Business Classes, and sub- 
components of Business Classes including, but not limited to, 
Business Processes and Business Rules. While the following 
detailed descriptions of the methods by which GUIs may be 

25 utilized to perform such diagramming are presented with 

reference to specific examples, the present invention is not 
limited to such examples. Rather, the GUI interfaces described 
herein are intended to broadly encompass any and all graphical 
means by which a user may interface with a computer, or other 

30 electronic device, for the purpose of accomplishing the 
intended task so described. 

As used herein, the term "repository" refers to any 
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aggregation of information whereon data is stored in an 
electronic format and may retrieved therefrom. As used herein, 
"electronic format" refers to any mode of storing or 
manipulating data in digital form. As used herein, "neutral 
5 format" refers to a data format which is capable of being 
expressed in or converted to at least one other computer 
language including, but not limited to, object oriented 
computer languages . 

With reference to Fig. 1, there is illustrated a graphical 

10 representation of a plurality of Business Classes, their 

organization, and relationships existing between them. Fig. 1 
comprises a Graphical User Interface (GUI) implemented in an 
Object Modeler 5, through which a user may model any business 
or process and the attendant operation thereof. Business 

15 Classes are grouped to form Subjects. Subjects are combined to 
form Packages. A Package is utilized to construct a Data 
Repository on an electronic storage medium. In the present 
example there is illustrated drugstore 11. Drugstore 11 is a 
Package comprised of Subjects customer 13, drugstore 15, store 

20 19, reference 17. Each Subject is further comprised of a 

plurality of Business Classes. A Subject represents a logical 
grouping of Business Classes. 

With continued reference to Fig. 1, store 19 is comprised 
of a plurality of Business Classes such as Product 30, 

25 BeautyProduct 31, HealthProduct 32, SalesOrder 21, Shipping 23, 
and SalesOrderltem 25. Subject Customer 13 is comprised of, 
Customer 27, and CustomerAddress 29. Using the GUI interface 
in a point-and-click manner, a user may define and thereby 
create Business Classes, drag them on a display device to a 

30 desired location, and define the logical relationship between 

the created Business Class and the other Business Classes. Once 
created and physically located at a desired point on the 
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display device, the user may define the relationships existing 
between the Business Class and other Business Classes in a GUI 
supported manner. For example, SalesOrder 21 was created and 
placed within store 19. A number of lines either eminating 
5 from or terminating at SalesOrder 21, with arrowheads located 
at at least one end of such each line's terminus, designates a 
relationship between SalesOrder 21 and a plurality of other 
Business Classes. Specifically, SalesOrder 21 can be seen to 
exist in relationships with SalesOrderltem 25, Shipping 23, 

10 Customer Payment 33, Customer 27, and Customer Address 29. One 
method by which Business Classes and relationships are defined 
and manipulated through the use of a GUI involves selecting a 
Business Class object from an object palette, dragging a 
representation of the Business Class object to a desired 

15 location on the user's desktop, and dropping the Business Class 
object at the location. A palette is a collection of icons 
from which a user may select a desired icon. Similarly, a 
relationship might be selected from a relationship palette and 
applied to a Business Class relationship indicated by a line 

20 connecting two Business Classes. The present invention is not 
limited to any one methodology but is intended to broadly 
encompass the process of using a GUI to diagram Business 
Classes and their relationships on a user's desktop. A user's 
desktop includes, but is not limited to, the portion of a 

25 viewing monitor within which an operating system displays 
graphical information to a user. 

As is indicated by the format of each line and the 
arrowheads attached thereto, the aforementioned relationships 
differ in substance from one another. While any method by 

30 which the nature of the lines is visually distinguishable by a 
user, in the present example lines are presented as either 
solid or dashed with the arrowheads affixed to at least one 
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terminus of each line represented as either solid or unfilled. 
A solid line indicates a relationship while a dashed line 
indicates ownership. A solid arrowhead indicates the nature of 
the derivation of a relationship while an unfilled arrowhead 

5 indicates inheritance. These concepts are described more 
particularly below. 

SalesOrder 21 has a relationship with Shipping 23 as 
evidenced by solid line 41 and solid arrowhead 43. As each 
sales order must be shipped, there is seen to be a relationship 

10 between the two Business Classes. While indicating a 

relationship, a solid line provides no further indication of 
the nature of that relationship. In contrast, dashed line 51 
between SalesOrder 21 and SalesOrderltem 25 indicates 
ownership. The orientation of filled arrowhead 53 terminating 

15 at SalesOrderltem 25 indicates that each SalesOrder 21 owns a 
SalesOrderltem 25. Similarly, each SalesOrder 21 owns a 
Cut omer Address 29. Note that this relationship exists among 
Business Classes contained in separate Subjects. SalesOrder 21 
is a member of store 19 while Customer Address 29 is a member of 

20 customer 13. Customer 27 is seen to own SalesOrder 21 via 

dashed line 55. Therefore, a Business class may own another 
Business Class as well as be owned by a third Business Class. 
In the present example, Customer 2 7 owns SalesOrder 21 and 
SalesOrder 21 owns SalesOrderltem 25. As will be illustrated, 

25 an ownership relationship imposes logical implications on 
software designed and implemented to carry out the tasks 
modeled in an Object Modeler. 

Product 30 is modeled as possessing relationships with a 
plurality of Business Classes such as BeautyProduct 31 and 

30 HealthProduct 32. Unfilled arrowhead 49 at the terminus of 
solid line 4 5 connecting HealthProduct 3 2 and Product 3 0 
indicate inheritance. The location of unfilled arrowhead at 



14 



102153-100 



Product 3 0 indicates that Business Class HealthProduct 32 is 
inherited from, and is thus the child of, parent Business Class 
Product 30. As such, Product 30 has been defined to be a 
template for products. The representation of HealthProduct 32 
5 and BeautyProduct 31 as children of Product 3 0 indicates that 
HealthProduct 32 and BeautyProduct 31 are specific instances of 
the more generalized Business Class 30. As such, HealthProduct 
32 and BeautyProduct 31 inherit all of the attributes of 
Product 30. While the user will likely add additional 

10 attributes to HealthProduct 32 and BeautyProduct 31 to reflect 
the unique characteristics of both, both Business Classes will 
always contain all of the attributes of the parent Product 30. 

The visually illustrated attributes of ownership and 
inheritance impose constraints on the more detailed 

15 descriptions of individual Business Classes. The present 

invention provides a method for translating the visual, GUI 
created Business Class model, into a repository based 
aggregation of data elements. Specifically, once defined using 
the GUI interface, the characteristics of each Business Class 

20 so defined are recorded in electronic format on a medium which 
is either centrally located or which may communicate with other 
like repositories. With reference to Fig. 2, the present 
invention comprises an electronic form or text based method for 
editing the properties of Business Classes. A Class Editor 211 

25 has a class layout portion 210 and an attribute portion 225. 
Class layout portion 210 is comprised of a plurality of icons 
arranged so as to illustrate logical groupings of Business 
Classes. In the present example, repository icon 215 indicates 
a repository containing all data defining the operation of a 

30 drugstore. The drugstore repository of the present example is 
comprised of a single drugstore Package as indicated by package 
icon 217. A Package is comprised of one or more subjects. The 
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drugstore Package is comprised of a plurality of Subjects each 
designated by a subject icon 219. Subject store 19 is 
illustrated as compromising a plurality of Business Classes. 
In the present example, SalesOrder 21 is designated as a 
5 Business Class by the corresponding business class icon 221. 

The text "SalesOrder" designating SalesOrder 21 is additionally 
illustrated as surrounded by a gray rectangle 243. The 
presence of the gray rectangle 243 is indicative of a user 
having selected the text through the GUI interface. Such 

10 selection may be accomplished through any appropriate means 

including, but not limited to, single-clicking upon the text. 

Class editor 211 is comprised of a series of "tabs" such 
as attribute tab 251. The tabs serve to logically arrange the 
plurality of aspects which comprise classes including, but not 

15 limited to, subjects, packages, and repositories. With respect 
to SalesOrder 21, selection by a user of attribute tab 251 
causes attribute table 225 to be displayed. Attribute table 
225 is comprised of attribute relationship column 253 and 
attribute name column 255. All of the relationships described 

20 above between Business Classes that were defined visually 

through the GUI by a user are automatically stored in a manner 
which allows for textual display in attribute table 225. In 
addition to the information which is derived from the graphical 
representation of Business Classes illustrated in Fig. 1, the 

25 user may enter additional information concerning the attributes 
of individual Business Classes which are not derived from their 
relationships with other Business Classes. 

Each attribute name listed in attribute name column 2 55 
has an associated value displayed in attribute relationship 

30 column 253. Possible values for attribute relationship column 
253 include U R" , "M" , W S" , U B" , and "E . " While the present 
implementation uses the aforementioned values, any values which 



16 



102153-100 



may be used that uniquely identify a plurality of attribute 
relationships. While, in the present example, attribute table 
225 includes an entry for each and every Business Class for a 
which a relationship was defined in Fig. 1, the entry in 
5 attribute name column 255 which represents a Business Class 
possessing a relationship with SalesOrder 21 does not 
necessarily bear the same name as the Business Class defined in 
Fig.l. This follows from the observation that while a single 
relationship may be established between two entities, the 

10 manner in which each entity views the relationship may vary. 

For example, consider two persons who are married. There 
exists a relationship between the two persons. This 
relationship is optimally a one-to-one relation as each person 
can be married to no more than one person. The relationship of 

15 marriage is the same relationship whether viewed from the 

perspective of the man or the woman. However, the woman views 
the person with whom she has a relationship as her husband 
while the man views the person with whom he has a relationship 
as his wife. Therefore, if the man is represented as a 

20 Business Class, it is preferable to have an entry in attribute 
table 22 5 identified as wife. Conversely, the same 
relationship viewed through the Business Class representing the 
woman might have an entry for a husband. The present invention 
provides a method whereby every Business Class can tie a 

25 preferred name to a relationship with another Business Class. 

As is illustrated graphically in Fig. 1, each SalesOrder 
21 is associated with a CustomerPayment 33. However, attribute 
name column 255 does not contain an entry for 

"CustomerPayment . " As illustrated in Fig. 3, when the row in 
30 attribute name column 225 containing the text "Payment" is 

selected, the variable name "CustomerPayment" appears in data 
type entry field 333. Therefore, referring once again to Fig. 
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2, the "Payment" entry in attribute name column 255 refers to 
the relationship between SalesOrder 21 and CustomerPayment 33. 

It will be noted that each entry in attribute name column 255 
has an associated entry in attribute relationship column 253. 
5 Every relationship between two Business Classes is bi- 
directional. An entry in the attribute relationship column 253 
further defines the nature of the relationship. 

An "M" entry indicates a one-to-many relationship. In 
attribute table 22 5, the "Orderltems" entry in attribute name 

10 column 2 55 indicates the relationship between SalesOrder 21 and 
SalesOrderltem 25. Associated with Orderltems is an attribute 
relationship of tt M. " This indicates that a single sales order 
can possess multiple order items. 

An "S" attribute indicates a relationship with a Business 

15 Class that itself possesses an "R" attribute. Returning to the 
example of a male class and a female class, the function of the 
W S" and W R" attributes is apparent. Because each male has one 
and only one wife, the male class will contain a wife attribute 
with an W S" relationship attribute. W S" refers to single, as 

20 in each male has a single wife. The female class will contain 
a husband attribute which stands in reference to the wife 
attribute of the male class. Therefore, the husband attribute 
of the female class will have an W R" attribute. In addition, 
there may exist instances where corresponding attributes in 

25 separate classes will exhibit an attribute relationship "M" and 
an attribute relationship "R." In the present example, a male 
class may have an attribute of daughter with an W M" attribute 
relationship while the female class will have an attribute of 
father with an W R" attribute relationship. This results from 

30 the fact that a male may have several daughters while each 
female has one and only one father. 

As noted, any number of attribute relationships may be 
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recorded and the present invention is not limited to those 
described. Rather, any relationship between Business Classes 
which may be conceived and which serves to define the operation 
of a Business Class may likewise be captured through the GUI, 
5 stored on the repository, and used to generate code and various 
other data entities related to the Business Class so defined. 

Referring to Fig. 2., attribute name "Customer" entered in 
attribute name column 255 has an associated attribute "R" 235. 
Attribute name "ShippingAddress" entered in attribute name 

10 column 255 has an associated attribute "S" 235. Therefore, 

SalesOrder 21 relates back to Customer 2 7 while CustomerAddress 
relates back to SalesOrder 21. 

The attribute "B" refers to a basic data type. A basic 
data type is usually implemented in computer code as a numeric 

15 value including, but not limited to, integers and floating 

point numbers. In addition, a basic type may be comprised of a 
byte sequence representing text. The attribute W E" refers to 
an enumerated data type. Enumerated data types contain integer 
values with each unique integer value representing a state as 

20 illustrated more fully below. Note that in Fig. 2, attribute 
name "StateVar" entered in attribute name column 255 has an 
associated attribute "E" 235. The gray area surrounding the 
text "StateVar" indicates that a user has selected the entry by 
clicking on the text or though other appropriate means. As a 

25 result of the selection, data type information is displayed in 
data type table 261. There is illustrated enumerated values of 
"1", "2", and "3" associated with states "Initiate" , 
"Registered", and "Payment Processed" respectively. 

A basic data type, such as "Taxes", may have one or more 

30 associated Business Rules. Business Rules are tied to 

attributes. With reference to Fig. 4, attribute "Taxes" has 
been selected and appears highlighted. As a result, Business 
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Rule button 41 is re-plotted with the annotation "(1) . " If 
more than one Business Rule were associated with "Taxes," the 
annotation appearing in Business Rule button 41 would reflect 
the number of Business Rules so associated. Clicking on 
5 Business Rule button 41 invokes Business Rule window 51 as 

illustrated in Fig. 5. Business Rule window 51 is comprised of 
Business Rule table 53 and business rule 55. Business Rule 
table 53 lists five types of Business Rules including, but not 
limited to, "Initial Value", "Derivation", and "Validation". 
10 An example of an initial value Business Rule would be 

"this .Quantity=0" . An example of a validation Business Rule 
might consist of the following code: 



If (this .Quantity > 0) 
15 return TRUE; 

else 

return FALSE; 

An example of a derivation Business Rule might consist of 
20 the following code: 



this .Quantityl = this . Quantity2 * this . Quant ity3 ; 

A Business Rule is comprised of logic which contains 
25 sufficient structure to enable the generation of computer 
executable code to perform the defined functionality. An 
example of such exemplary code is "this . SubTotal*0 . 06" . 
Business Rules may be tied to an entire Business Class, and 
hence to all Business Objects derived therefrom, or to an 
30 individual instance of a Business Class. 

In the present example, business rule 55 is comprised of 
the following logic: "this . SubTotal*0 . 06" . Because business 
rule 55 is of type "Derivation," the logic serves to specify 
how the value of taxes attribute is derived or computed. Using 

20 
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logic descriptors similar to the syntax of C++, business rule 
55 states that the value of taxes attribute 43 is to equal the 
value of attribute subtotal 45 multiplied by 0.06. Attribute 
subtotal 45 may itself derive its value from a Business Rule 
5 which states a dependence on one or more other attributes. As 
illustrated, all SalesOrder Business objects derived from the 
SalesOrder Business Class will inherit the described taxes 
business rule 55. However, it is preferable to have a method 
by which the individual attributes of Business Objects are 
10 derived and processed different from one another based upon the 
unique characteristics of the Business Object. The present 
invention allows for the incorporation into a Business Rule of 
logic which is specific to a particular instantiation of a 
Business Object. 

15 For example, to calculate a separate discount rate for 

businesses purchasing goods from a particular web site one 
could code a derivation Business Rule which would return a 
different discount rate based upon the identity of the buyer. 
Such a Business Rule might appear as follows: 

20 

if this . customer = "Joe" 

then this . discount = .06; 
else if this . customer = "Fred" 

then this discount = .09; 
25 else if this . customer = "John" 

then this .discount = ".03"; 

In this manner, different customers would receive 
different discount rates. However, such a methodology relies 
30 on hard- coding the identity of customers and their attendant 
discount rates. Using such a methodology presents challenges 
when a new customer is added. Specifically, such a methodology 
requires that the Business Rule within which each separate 
discount rate is specified contains a hard-coded algorithm for 
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deriving the appropriate discount rate for a given customer. 
If in the future another customer were added, it would be 
necessary to re-code the Business Rule to include new discount 
rate derivation code, regenerate the run time application 
5 components of the architecture, and redistribute the new 

components. Such a process requires considerable new code to 
be added to an existing architecture requiring potentially 
laborious testing. 

The present invention avoids these drawbacks by allowing a 

10 reference in a Business Rule to a row and column in a 

relational database associated with a defined attribute. While 
the present invention is illustrated herein with reference to a 
relational database, the present invention is drawn broadly to 
the use of any form of memory storage capable of receiving a 

15 request for data based upon identifying criteria and returning 
the data so requested. In this manner, one is able to locate a 
portion of the logical code comprising a Business Rule outside 
of the Business Rule definition contained in a Business Class. 
When such a Business Rule is invoked at run- time, the 

20 referenced portion of the Business Rule located externally in 
the relational database is retrieved and executed. Such 
execution may consist of interpreting the code or compiling and 
subsequently executing the code. The result of such a method 
is the ability to change the functionality of a statically 

25 defined Business Rule based upon the identity of a customer or 
other Business Class attribute. 

As has been illustrated, the attributes corresponding to a 
Business Class fall generally into two groups, those which can 
be derived from the graphic representation of Business Class 

30 relationships as illustrated in Fig. 1, and those which must be 
manually defined. Regardless of which of the two types into 
which an individual attribute falls, Business Rules may be 
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defined and tied to the attribute. Regardless of whether a 
Business Rule accesses the values of other attributes, each 
Business Rule is tied to one and only one attribute. In 
contrast to the attribute dependent nature of Business Rules, 
5 there exists Business Class level Business Processes which are 
tied to individual Business Classes. Like Business Classes, 
however, a portion of the logic required to implement Business 
Processes may be derived from a graphical representation of the 
relationship between Business Processes. 

10 Business Processes are comprised of states and 

subprocesses, may be comprised of one or more Business Methods, 
or may consist of one or more manual processes. A state is the 
present condition of a Business Class. As detailed with 
reference to Fig. 2, attribute "StateVar" is an enumerated data 

15 type where possible states include "Initiate," Registered, " 

and "Payment Processed." Subprocesses consist of the logic or 
operations required to move a Business Class from state to 
state. Fig. 6 illustrates the GUI interface for the present 
invention's Business Process Editor 611. Business Process 

20 Editor 611 allows the user to define states 613, and 621, 

Subprocesses 615 and 617, and the states 619, 623 which result 
from the operation of Subprocesses. Focusing on a portion of 
the state diagram illustrated in Business Process Editor 611, 
the user has created elliptical state icons 613 and 621, 

25 rectangular Subprocess icons 615 and 617, and rectangular state 
icons 619 and 623 attached thereto. Such shapes are exemplary 
and not required. The portion of the Business Process thusly 
comprised illustrates the initial state of the Business Class 
SalesOrder shown as initiate state 613, and the Business 

30 Methods validate user 615 and registration 617 required to move 
Business Class SalesOrder to registered state 621. 
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As is illustrated, the user has created an icon and 
assigned a textual attribute of "initiate" to form initiate 
state 613. Next, the user defined two Business Methods in 
series with initiate state 613 and connected by arrow lines 
631. The Business Methods were next assigned the textual 
attributes of "Validate User' 7 and "Registration" to form 
validate method 615 and registration method 617. Associated 
with each method 615, 617 are the states resulting from the 
operation of the methods. In the present example, the user has 
defined two possible outcomes for validate method 615: 
registered or unregistered. Similarly, the user has defined 
two possible outcomes for registration method 517: success or 
error. Connected to registration method 617 via arrow line 631 
is registered state 621. Each arrow line 631 indicates the 
direction of logical flow of the Business Process. In the 
present example a sales order with a state of "initiate" 
proceeds to validate the user. The diagram of Fig. 5 
illustrates that the process of user validation will be 
accomplished through the implementation of a Business Method 
identified as validate method 615. Upon completion of 
performing validate method 615, the state of the user will be 
either "registered" or "unregistered". If the result is 
"registered,' 7 the logical flow continues, via arrow line 631, 
directly to registered state 621. If the result is 
"unregistered," the logical flow continues to registration 
method 617. Upon completion of performing registration method 
617, the state of the registration will be either "success" or 
"error". If the result is "success," the logical flow 
continues, via arrow line 631, directly to registered state 
621. If the result is "error," the logical flow continues to 
perform once again registration method 617. 
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In a manner similar to that illustrated with reference to 
Fig. 1 and Object Modeler 5, Business Process Editor 611 allows 
a user, through the utilization of a GUI, to define the logical 
relationship between entities. While Object Modeler 5 allows 
the user to define the relationship between Business Classes, 
Business Process Editor 611 allows the user to define the 
relationship between Business Class states and Business 
Methods. In addition, Business Process Editor 611 also allows 
for the conversion of user defined graphical relationships into 
detailed, logical abstractions which facilitate the creation of 
computer code necessary to perform the Business Process so 
defined. 

As described above with reference to Fig. 2, there is 
illustrated attribute name "StateVar" entered in attribute name 
column 255 with an associated attribute U E" 235. There is 
additionally illustrated enumerated values of "1", "2", and "3" 
associated with states "Initiate", "Registered", and w Payment 
Processed" respectively. These states were derived from the 
graphical description of the Business Process illustrated in 
Fig. 6. With reference to Fig. 7, there is illustrated the GUI 
utilized by a user to define Business Methods. Note, as with 
Fig. 2, SalesOrder 21 is selected. Once selected, the user may 
click, or otherwise select, agents tab 711 to display Business 
Method information. Selecting agents tab 711 causes Business 
Method table 713 and Business Method code window 715 to be 
displayed. Business Method table 713 lists all Business 
Methods associated with SalesOrder 21. Some of these Business 
Methods are derived from the relationships specified 
graphically in Business Process Editor 511 and some are user 
defined Business Methods not derivable from information entered 
into Business Process editor 511. Still other Business Methods 
are derived from the Business Class relationships specified in 
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Object Modeler 5 as illustrated in Fig. 1. 

With reference to Fig. 7, there is seen Business Method 
table 713. Business Method table 713 is comprised of multiple 
Business Methods. Among these Business Methods are 
5 "ProcValidateUser" and "ProcRegistration . " ProcValidateUser 
and ProcRegistration refer to validate method 615 and 
registration method 617. As a result of the user defining 
validate method 615 and registration method 617 using Business 
Process Editor 611, the names of the methods 615, 617 appear in 

10 Business Method table 713. The gray rectangle surrounding the 
text "ProcValidateUser" indicates that the user has selected 
the first row of the Business Method table 713 . As a result of 
the selection, the code which forms the substance of validate 
method 615 appears in Business Method code window 715. If code 

15 associated with validate method 615 has been previously entered 
into Business Method code window 715, the code will appear in 
Business Method code window 715. In addition, code may be 
added or modified by altering the contents of Business Method 
code window 715. 

20 In addition to the Business Methods whose names are 

automatically generated based upon the inputs to the Business 
Process Editor 611, the present invention can generate both 
entries and the attendant code for other standard Business 
Methods. As mentioned, each attribute comprising a Business 

25 Class may have a validation Business Rule associated with it. 
Such a Business Rule provides logic for determining the 
validity of the attribute to which it is tied. However, 
Business Rules can only be tied to single attributes. Business 
Methods, on the other hand, are tied to Business Classes and, 

30 as such, may operate on one or more attributes. Because of 
this property, it is possible to generate a plurality of 
Business Methods. For example, there can be generated, and the 
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present invention does generate, a Business Method which 
automatically invokes the validation Business Rules tied to 
each attribute in order to establish a Business Class 
validation . 

5 In addition to creating standard attribute validation, the 

present invention is capable of generating Business Methods to 
perform Business Class management functions. Such functions 
manage the allocation of memory comprising the persistent and 
transient electronic data storage space which define the run- 

10 time characteristics of a Business Class. As illustrated in 
Fig. 1 and discussed above, SalesOrder 21 has a one- to-many 
relationship with SalesOrderltem 25. That is to say that one 
SalesOrder 21 may have a plurality of SalesOrderltems 25. 
While not illustrated herein, it is likewise possible that each 

15 SalesOrderltem 25 could have a one-to-many relationship with 
another Business Class. If, while executing the Business 
Process comprising the SalesOrder Business Class, it becomes 
necessary to abort the processing of a sales order, it is 
preferable to be able to delete all the dependent instances of 

20 Business Classes which have been created and are in existence. 
It is therefore one aspect of the present invention to 
automatically generate for each Business Class the Business 
Methods required to handle the deletion of dependent Business 
Classes and their attendant data. 

25 The present invention allows the user to define each 

Business Class as being of type "restrict" or type "cascade . " 
If a Business Class is of type "cascade," the run-time 
embodiment of the Business Class, when no longer valid, will 
propagate the requirement of deleting dependent Business 

30 Classes. As each dependent Business Class may itself comprise 
further dependent Business Classes, the deletion logic will 
propagate in tree like fashion from the original Business Class 
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to the last Business Class or Classes dependent thereupon. If, 
conversely, a Business Class is of type "restrict," the run- 
time embodiment of the Business Class, when no longer valid, 
will not proceed to extinguish itself if there are existing 
5 Business Classes dependent thereupon. 

The present invention automatically generates Business 
Methods for each Business Class to allow for the management of 
Business Class deletions. The generation process flows 
sequentially from the repository in which are stored the 

10 Business Classes comprising an application to the run-time 

components capable of deployment throughout the architecture on 
which they are to run. The Business Class definitons residing 
in the repository form an integrated description of the 
business model referred to as a knowledge base. Once the 

15 knowledge base is created, technology choices, or selections, 
are inputed to direct the generation of individual run-time 
components. For example, a user might designate the generation 
of C++ code and JAVASCRIPT code to be generated for 
distribution to different platforms. Once the technology is 

20 selected, the present invention proceeds to translate the 
neutral code of the Business Classes into the designated 
technology specific language thus building the completed run- 
time application which forms the output of the present 
invention. In addition, the process of building the application 

25 may include the additional step of compiling the generated run- 
time components to create executable code. After building the 
application, the generated and executable components are 
deployed to the platforms upon which they will execute. This 
process of code generation is graphically depicted in flow 

30 chart form with reference to Fig. 8. 

The code comprising each such Business Method is generated 
for inclusion by the user into other Business Methods. The 
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generated code allows for the deletion of both the persistent 
and the non-persistent, or transient, data which comprises a 
Business Class. As noted, a Business Class forms the template 
for a particular run- time Business Object. The Business Object 
5 is an instance of the Business Class. 

A Business Object, when implemented in computer code 
forming the run time manifestation of the Business Object, 
comprises persistent and transient representations. For 
example, there may exist an instance of the SalesOrder Business 

10 Class representing an actual run- time sales order. This sales 
order Business Object, comprising attributes and the attendant 
functionality required to implement the defined Business 
Processes and Business Rules, is located in a defined portion 
of memory in an electronic storage device. This portion of 

15 memory may consist of, but is not limited to, the RAM memory of 
the user's computer. This memory space is likely comprised of 
contiguous memory addresses and may be allocated and de- 
allocated as required by the operating system on the user's 
computer. While the values stored in the memory space 

20 comprised of the structure of the sales order Business Class 
may change, the amount of memory initially allocated is 
unlikely to do so. For example, when a derivation Business 
Rule associated with an attribute of a Business Object is 
invoked, the resulting value is stored in the corresponding 

25 attribute variable of the Business Object. While the value in 
memory may be changed by such an operation, the amount of 
memory space is unchanged. If the entire memory space 
containing the structure of the individual Business Object were 
de-allocated, as when the Business Object is deleted, the 

30 Business Object would cease to exist. 

However, there is additionally data associated with a 
Business Object that may persist even after the memory space 
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comprising the Business Object is de- allocated. For example, a 
SalesOrder Business Object may keep track of the sales items of 
which it is comprised by storing tabular information in a 
relational database or other suitable data storage medium. 
5 When the transient memory space comprising the Business Object 
is de-allocated, this tabular data will persist. In many 
instances, it is the tabular data associated with a Business 
Object that is most important to delete when the instance of 
the Business Object is no longer required. Therefore , the 

10 present invention automatically generates Business Methods to 
de-allocate the memory storage space comprising the transient 
Business Class data as well as those necessary to delete the 
non-persistent data. Examples of the later Business Methods 
may include, but are not limited to, SQL statements. 

15 In addition to the aforementioned methodologies for 

entering Business Rules and Business Methods, the present 
invention provides a methodology for defining and generating 
web pages in a fashion which is fully integrated with the 
definition of other Business Class attributes. 

20 With reference to Fig. 9 there is illustrated the GUI 

comprising, in part, web page editor 911. Web page editor 911 
consists of web page space 915 representing the space upon 
which graphic and textual elements may be added so as to design 
a web page. Element selection menu 913 is a collection of 

25 icons representing different graphic and textual elements. As 
shall be more fully illustrated below, elements selected from 
element selection menu 913 can be selected and placed upon web 
page space 915 to design and define the layout of a web page. 

After entering web page editor 911, the present invention 

30 allows definition at the micro and macro levels of the 

attributes which define the web page as a whole and each 
graphic or textual element individually. Referring to Fig. 10, 



30 



102153-100 



there is illustrated web page properties editor 1011. Web page 
properties editor 1011 may be invoked from the web page editor 
911 of Fig. 9 in any of a number of appropriate manners 
including, but not limited to, clicking on a push button or 
5 selecting a tab. 

Once web page properties editor 1011 is invoked, there is 
provided a series of tabs such as form tab 1017 and object 
space tab 1019. In the present example, form tab 1017 has been 
selected and as a result a series of entry fields are displayed 

10 into which customizing data relating to the web page can be 
entered. Selecting any of the tabs will invoke a separate 
window interface through which information about the web page 
or one of its elements may be entered. A variety of input 
fields, such as exemplary input field 1013, is included within 

15 web page properties editor 1019. In the present instance, 

there are displayed a plurality of input fields through which 
there can be defined a plurality of web page attributes 
including, but not limited to, a web page's name, title, theme, 
and style. While illustrated herein with a variety of specific 

20 input fields, the present invention is drawn broadly to the 
inclusion of any and all input fields, of any appropriate 
construct, which allow the definition of web page attributes. 
Of note is data binding input field 1015 wherein can be entered 
the mode by which the web page is to be created and accessed. 

25 With reference to Fig. 10a, there is illustrated data 

binding input field 1015 as a drop down list box 1017. 
Possible selections include "dynamic" , "static" , and "auto" . 
Selection of static binding will allow the run-time 
architecture to dynamically update the code comprising the web 

30 page at predefined intervals allowing the web page to be stored 
and accessed as a static web page. Selection of dynamic data 
binding will provide through the generation of web page code, 
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such as HTML code, of a web page which may be accessed through 
the run-time architecture. Selection of auto data binding will 
ensure that the web page is generated according to the same 
data binding option selected in the Business Class in which the 
5 web page resides. 

The present invention allows for, but does not require, 
the definition of the object space associated with any web 
page. As used herein, "object space", refers to the subset of 
attributes, methods, and rules contained in one or more 

10 Business Class definitions which defines the specific 

functionality required to perform a discreet business function. 

Use of an object space obviates the difficulties inherent in 
web based transactions arising from the stateless nature of web 
based communications. With reference to Fig. 11, there is 

15 illustrated web page properties editor 1011 after selection of 
object space tab 1019. Displayed are entity selection window 
1113, available attribute window 1121, current entity window 
1115. Data is moved from one window to another through the use 
of add entity button 1117 and add attribute button 1119. In 

20 the present example Business Class customer has been selected 
and appears highlighted in entity selection window 1113 . Once 
a Business Class has been selected, clicking on add entity 
button 1117 causes all of the attribute, methods and messages 
of the selected Business Class to appear in available attribute 

25 window 1121. Once included in available attribute window 1121, 
selecting an attribute, method, or message followed by clicking 
on add attribute button 1119 will add the selected attribute to 
current entity window 1115. Current entity window 115 contains 
all of the attributes, methods, and messages which comprise the 

30 object space associated with the web page. As used herein, a 
message refers to a sequence of one or more bytes of data 
which, like a web page definition, has an associated format and 
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object space and may interact with other Business Classes or 
external code. 

Whether or not an object space is defined, it is necessary 
to return to the web page editor 911 of Fig. 9 and to design 
5 the web page by placing graphic and textual elements on the web 
page and associating each element with a Business Class 
attribute definition. With reference to Fig. 12, there is 
illustrated web page editor 911 after selection and positioning 
of exemplary text field 1213 and button 1211 on web page space 

10 915. One method of accomplishing such selection and 

positioning involves clicking on the icon in element selection 
menu 913 that corresponds to the element to be placed upon web 
page space 915 and then clicking on the desired location in web 
page space 915 where the chosen element is to reside. Once 

15 placed in this manner, the element, such as text field 1213 and 
button 1211, may be selected and moved around web page space 
915 as desired in accordance with any of a number of 
methodologies, including but not limited to, dragging and 
dropping the element at a new location. 

20 Once graphic and textual elements have been added, their 

properties must be defined. Note that in the present example 
attribute window 1215 contains data previously selected when 
defining the web page's object space. Through any appropriate 
manner of clicking on a single element in attribute list window 

25 1215 and an element such as text field 1213, the attribute 
definition of a Business Class attribute may be linked to 
graphic or textual element on web page space 915. In this 
manner, information contained in a Business Class definition is 
automatically linked to the web page element. As mentioned, 

30 while an object space may be defined for web page before adding 
elements to the web page space 915, it need not be predefined. 
In the present example, the specialized attributes which 
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define the operation of a web page element may be entered 
without reference to an existing Business Class. In the 
present invention, one may invoke a control properties window 
to enter data particular to a specific element or control. 
5 With reference to Fig. 13, there is illustrated the 

control property editor of the present invention. Invoked by 
the selection of an element placed in web page space 915 of 
Fig. 9, control property window 1311 allows for the entering of 
attributes which define the appearance and operation of an 

10 element. For example, control property window 1311 is 

comprised in part of exemplary entry field 1313 into which a 
font type is entered. The present invention is drawn broadly 
to any and all assemblages of entry fields or other data entry 
elements through which the appearance and operation of any and 

15 all types of graphic or textual elements may be defined. 

Once the attributes of the web page and each element of 
the web page have been defined, the code for each web page may 
be generated. With reference to Fig. 14, there is illustrated 
generate HTML window 1411. While illustrated with reference to 

20 generating HTML code, the present invention is drawn broadly to 
the generation of any and all web based programming languages. 

Generate HTML window 1411 includes data binding selection 1415 
and target browser 1413. Once the method of data binding is 
selected through the use of data binding selection 1415 and the 

25 target browser is selected through the use of target browser 

1413, clicking on generate button 1417 will cause the web pages 
defined by the present invention to be generated into run-time 
code reflecting the defined appearance and functionality of the 
web pages so defined. 

30 With reference to Fig. 17, there is illustrated a typical 

web page 1731 as known from the prior art. The HTML code which 
defines web page 1731 is presented in HTML code 1735. When 
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HTML code 173 5 is returned to and displayed by a web browser 
1511, the resulting web page 1731 comprises the text 1733. In 
the present example, web page 1731 was most probably requested 
from a previous web page (not shown) . The request explicitly 
5 requested the retrieval of HTML code 1735 by its file name 

"ProductPage.htm." When this request is received by web server 
1519, the page named "ProductPage.htm" is retrieved and sent to 
web browser 1511 where the browser interprets HTML code 1735 
and displays it as web page 1731. The Object Modeler of the 

10 present invention allows for the detailed specification of Web 
Pages. Each Web Page may be defined as being static or dynamic 
in nature. When the code generation utility of the present 
invention is invoked to create a page which is static in 
nature, the exemplary resulting HTML code 35 is produced. This 

15 code is illustrated as follows: 
<HTML> 

Product Price is $2 0 
<HTML> 

Alternatively, if a Web Page is defined that comprises at 
20 least one dynamic element requiring access to relational 

database 1625, the resulting code will most likely be in ASP 
format. With reference to Fig. 18, there is illustrated the 
identical display of web page 1731 from Fig. 17 shown as web 
page 1841. While web page 1731 and web page 1841 appear within 
25 web browser 1511 as identical, the manner in which the code is 
retrieved to display either web page 1731 or web page 1841 is 
different. With respect to web page 1731, HTML code 1735 was 
requested by name and the corresponding HTML code was returned. 
With reference to web page 1841, the invocation of ASP code 
30 was requested. The ASP code, illustrated as ASP code 184 7 was 
executed on web server 1519, as illustrated in Fig. 16, 
interacted with operational database 1625 to retrieve the 
product price, as illustrated in Fig. 16, and produced HTML 
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code identical to the HTML code 1735 of Fig. 17 on executable 
repository 1623, as illustrated in Fig. 16. Referring again to 
Fig. 18, this HTML code was sent back to the requesting web 
browser 1511 and displayed as web page 1841. Although not 
noticeable to a viewer, web page 1841 is illustrated as 
incorporating both static elements 1845 and dynamic element 
1843. Dynamic element 1843 was retrieved from operational 
database 1625 and incorporated into the HTML code to be 
returned to web browser 1511. This process of incorporation is 
described more fully below. 

Examining the generated ASP code 47, it can be seen that, 
when executed, the ASP code 47 will output directly to 
executable repository 23 the following code: 

< HTML > 

Product Price is $ 

At this point, the presence of delimiters "<%" and "%>" 
indicates the requirement to perform the function "Product" 
whose code is not portrayed. While such delimiters are native 
to ASP, any method whereby dynamic code is ifdentified for 
execution may be employed. When completed, the "Product" 
function (not shown) will have accessed and retrieved the 
desired product price and outputted the result, in this case 
"20", to executable repository 1623. Finally the code "<HTML> 
will be outputted to executable repository 1623 and the 
completed HTML file will be sent back to the requesting web 
browser 1511. 

It is therefore seen that from a user's perspective, it is 
not discernable whether the web page was requested as static 
HTML code or was assembled by executable 1621 through the 
execution of ASP code which assembled the requested HTML code. 
However, it is one aspect of the present invention that, in 
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addition to defining a Web Page as static or dynamic, a web 
page may be defined as being quasi - static . That is to say, the 
Web Page contains at least one dynamic element but the rate at 
which the dynamic data changes is either slow or may be well 
defined . 

In such an instance, the present invention generates two 
complimentary pieces of code. With reference to Fig. 20, there 
is illustrated the interaction of these two pieces of code. 
The first piece of code is executable 1621. The second piece 
of code, located within web server 1519 is scheduler code 2061. 

Scheduler code 2 061 is generated code which contains 
information on which executables are to be executed and how 
often. While illustrated as a flat file containing information 
regarding executables and the schedule on which they are to be 
invoked, the present invention is drawn broadly to any method 
whereby such scheduling information may be stored and retrieved 

including, but not limited to, the use of a relational 
database. Scheduler code 2061 is typically accessed by a long 
running executable which continually queries the system time of 
the platform on which it resides. When the time interval since 
the last scheduled update of an executable defined in scheduler 
code 2061 has elapsed, the long running executable invokes the 
execution of the required executable. In this manner, 
executables 1621 such as those comprised of ASP code, are 
executed on a desired basis with the resulting static HTML 
pages stored on executable repository 1623. In fact, the 
static HTML pages may be stored anywhere on web server 
component 1517 that possesses connectivity to web sever 1519. 

In addition to generating the code for executable 1621 and 
scheduler 2061, the code invoked by web pages to access an HTML 
page which is periodically updated by scheduler 2061 invoking 
an executable 1621 is generated to request a static HTML page. 
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In this manner, a Web Page containing dynamic elements, is 
requested as a static Web Page. It is one aspect of the 
present invention to define web pages as associated with a 
specific Business Class definition. Because the logical 
connections between Business Classes, and hence web pages, are 
defined, when a web page containing dynamic elements is defined 
as static, the code of other web pages which might access the 
static defined web page may be automatically generated to 
request a static web page. When the request for the static Web 
Page is received by the web server 1519, web server 1519 
retrieves the most recently generated HTML code which satisfies 
the request and returns it to the requesting web browser 1511. 
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CLAIMS 



WHAT IS CLAIMED IS: 

l.y A method for providing a requestor with access to dynamic 



data via quasi-static data requests, comprising the steps 



a. defining a web page, said web page including at 
least one dynamic element; 

b. creating an executable digital code to be run on a 
computer and invoked at defined intervals by a 
scheduler component said executable code effective 
to create and storing a quasi-static copy of said 
defined web page; 

c. creating said scheduler component capable of 
invoking said executable code at predefined 
intervals ; 

d. loading said executable code and said scheduler 
component onto a platform in connectivity with a 
web server and with one another ; 

e. invoking execution of said scheduler component; and 

f . retrieving and returning the static copy of said 
defined web page in response to requests for said 
defined web page. 



2 . The method of claim 1 wherein said web page is defined and 
stored in a centralized repository. 

3 . The method of claim 2 wherein defining said web page 
comprises the steps of: 



a. defining the placement and method of derivation for 
all elements comprising said web page; and 

b. defining said web page as either static or dynamic 
in nature . 
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4 . The method of claim 3 wherein said elements are defined as 
dynamic or static in nature. 

5. The method of claim 4 wherein the creation of said 
executable code and the creation of the scheduler 
component is generated from Business Class definitions 
comprised of said defined web pages. 

6. The method of claim 5 wherein said static copy of said 
defined web page is stored in a format capable of being 
viewed by a web browser. 
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ABSTRACT 

A method for providing a requestor with access to dynamic 
data via quasi -static data requests, comprising the steps of 
defining a web page, the web page including at least one 
dynamic element, creating an executable digital code to be run 
5 on a computer and invoked at defined intervals by a scheduler 
component the executable code effective to create and storing a 
quasi-static copy of the defined web page, creating the 
scheduler component capable of invoking the executable code at 
predefined intervals, loading the executable code and the 
10 scheduler component onto a platform in connectivity with a web 
server and with one another, invoking execution of the 
scheduler component, and retrieving and returning the static 
copy of the defined web page in response to requests for the 
defined web page. 

15 
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COMBINED DECLARATION AND POWER OF 
ATTORNEY FOR JOINT INVENTORS 



1. As below named joint inventors, we hereby declare that our addresses and 
citizenship are as stated below next to our names. We believe we are the 
original, first, and joint inventors of the subject matter which is claimed and for 
which a patent is sought on the invention entitled: 

AN OBJECT ORIENTED BASED. BUSTNKSS CLASS METHODOLOGY FOR 
GFNER ATTNG OUAST-STATIC WEB PAGES 



the specification of which: 

[X] is attached; or 

| | was filed on as Serial No. 



2. We hereby state that we have reviewed and understand the contents of the 
above-identified specification, including the claims, as amended by any 
amendment referred to above. 

3. We acknowledge the duty to disclose information which is material to the 
patentability of this application as defined in 37 C.RR. 1.56. 



4. □ Because this is a continuation-in-part application, we acknowledge our 

duty to disclose to the Office all information known to us to be material 
to the patentability as defined in 37 C.F.R. § 1.56 which has become 
available between the filing date of the prior application and the filing 
date of this continuation-in-part application. 

5. We hereby claim foreign priority benefits under Title 35, United States 
Code, §119(a)-(d) or §365 (b) of any foreign application(s) for patent or 
inventor's certificate or §365(a) of any PCT international application(s) 
designating at least one country other than the United States of America 
listed below and have also identified below any foreign application(s) for 
patent or inventor's certificate or any PCT international application(s) 



designating at least one country other than the United States of America 
filed by us on the same subject matter having a filing date before that of 
the application(s) of which priority is claimed: 



Country 


Application Serial No. 


Date of Filing 


Priority Claimed 1 
under 35 U.S.C.§ 119 








□Yes 


□ No 








□ Yes 


□ No 








□ Yes 


□ No 



6. □ We hereby claim the benefit under Title 35, United States Code, §120 of 
any United States application(s), §365(c) of any PCT international 
application designating the United States of America, and §1 19(e) of any 
United States provisional application(s) that is/are listed below and, 
insofar as the subject matter of each of the claims of this application is 
not disclosed in that/those prior applications(s) in the manner provided 
by the first paragraph of Title 35, United States Code, § 112, we 
acknowledge the duty to disclose material information as defined in Title 
37 C.RR. § 1.56 which became available between the filing date of the 
prior application(s) and the filing date of this application: 



Application Serial No. 


Filing Date 


Status 















7. We hereby declare that all statements made herein of our own knowledge are 
true and that all statements made on information and belief are believed to be 
true; and further that these statements were made with the knowledge that 
willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of the 
application or any patent issuing thereon. 



8. As named inventors, we hereby appoint the following attorneys of the law firm 
of Wiggin & Dana to prosecute this application and transact all business in the 
Patent and Trademark Office connected therewith: Dale L. Carlson, Reg. No. 
28,784; Jody L. DeStefanis, Reg. No. 44,653; Todd E. Garabedian, Ph.D., Reg. 
No. 39,197; Gregory S. Rosenblatt, Reg. No. 32,489; William A. Simons, Reg. 
No. 27,096; William B. Slate, Reg. No. 37,238 and William J. Speranza, Reg. 
No. 26,340. 

9. Please send all correspondence to: 

Gregory S. Rosenblatt 

Intellectual Property Law Section 

Wiggin & Dana 

One Century Tower 

New Haven, Connecticut 06508-1832 

Telephone: (203) 498-4566 

10. □ As named inventors, we hereby appoint the attorneys listed in paragraph 

8 as our domestic representative for the invention identified in paragraph 
1 with full power of substitution and revocation, to transact all business 
in the U.S. Patent and Trademark Office and in the U.S. courts in 
connection therewith. He is also designated as domestic representative 
on whom process or notice of proceedings affecting the application or 
patents issuing therefrom may be served. 

[X] We hereby authorize the U.S. attorneys named in paragraph 8 to accept 
and follow instruction from NeuVis Incorporated as to any actions to be 
taken in the U.S. Patent and Trademark Office regarding this application 
without direct communication between the U.S. attorneys and us. In the 
event of a change in the person from whom instructions may be taken, 
we will notify the U.S. attorneys. 



1 1 . Inventor Information: 



Full name of first joint inventor: Arun K. Gupta 

Inventor's signature v ^>4^ wl^ \l . Jl^^U^ 

Date: S^xv |o o Citizenship: India 

Residence: 120 Buckhill Road, Easton, Connecticut 06612 

Post Office Address: 120 Buckhill Road, Easton, Connecticut 06612 



Full name of second joint inventor: Rajw K. Uppal 




Inventor's signature 
Date: ^j^ffa ® Citizenship 
Residence: 2295 Huntington Road, Trumbull, Connecticut 06611 
Post Office Address: 2295 Huntington Road, Trumbull, Connecticut 0661 1 



Full name of third joint inventor: Devang L Parikh 

Inventor's signature: _ 

Date: vfx\[a a Citizenship: India 

Residence: 21 Far Horizons Drive, Bethel, Connecticut 06801 

Post Office Address: 21 Far Horizons Drive, Bethel, Connecticut 06801 

This is the end of the listing of inventors. 
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